I was assigned 12.75 hours of work by Freexian's Debian LTS initiative and carried over 5.5 from December. I worked only 3 hours, so I carry over 15.25 hours - but I will probably give up some of those to the general pool. I spent some time finishing off the linux security update mentioned in my December entry. I also backported the current version of wireless-regdb - not a security update, but an important one anyway - and issued DLA 785-1.

There are a fair number of outstanding security issues in the Linux kernel for Debian 8 "jessie", but none of them were considered serious enough to issue a security update and DSA. Instead, most of them are being fixed through the point release (8.7) which will be released this weekend. Don't forget that you need to reboot to complete a kernel upgrade. This update to linux (version 3.16.39-1) also adds the perf security mitigation feature from Grsecurity. You can disable unprivileged use of perf entirely by setting sysctl kernel.perf_event_paranoid=3. (This is the default for Debian "stretch".)

I was assigned 13.5 hours of work by Freexian's Debian LTS initiative and carried over 2 from November. I worked only 10 hours, so I carry over 5.5 hours. As for the last few months, I spent all of this time working on the linux (kernel) package. I backported several security fixes and did some testing of the more invasive changes. I also added the option to mitigate security issues in the performance events (perf) subsystem by disabling use by unprivileged users. This feature comes from Grsecurity and has been included in Debian unstable and Android kernels for a while. However, for Debian 7 LTS it has to be explicitly enabled by setting sysctl kernel.perf_event_paranoid=3. I uploaded these changes as linux 3.2.84-1 and then (on 1st January) issued DLA 722-1.

I was assigned 11 hours of work by Freexian's Debian LTS initiative. I worked 9 hours and carry over 2 hours. In my role as Linux 3.2 stable maintainer, I made a 3.2.84 release with a large number of backported fixes. I then rebased wheezy's linux package on this and made some additional changes to maintain the kernel module ABI. This will probably be released some time in December or January, depending on what security issues turn up.

I attended this year's Linux Kernel Summit in Santa Fe, NM, USA and made notes on some of the sessions that were relevant to Debian. LWN also reported many of the discussions. This is the second and last part of my notes; part 1 is here. Kernel Hardening Kees Cook presented the ongoing work on upstream kernel hardening, also known as the Kernel Self-Protection Project or KSPP. GCC plugins The kernel build system can now build and use GCC plugins to implement some protections. This requires gcc 4.5 and the plugin headers installed. It has been tested on x86, arm, and arm64. It is disabled by CONFIG_COMPILE_TEST because CI systems using allmodconfig/allyesconfig probably don't have those installed, but this ought to be changed at some point. There was a question as to how plugin headers should be installed for cross-compilers or custom compilers, but I didn't hear a clear answer to this. Kees has been prodding distribution gcc maintainers to package them. Mark Brown mentioned the Linaro toolchain being widely used; Kees has not talked to its maintainers yet. Probabilistic protections These protections are based on hidden state that an attacker will need to discover in order to make an effective attack; they reduce the probability of success but don't prevent it entirely. Kernel address space layout randomisation (KASLR) has now been implemented on x86, arm64, and mips for the kernel image. (Debian enables this.) However there are still lots of information leaks that defeat this. This could theoretically be improved by relocating different sections or smaller parts of the kernel independently, but this requires re-linking at boot. Aside from software information leaks, the branch target predictor on (common implementations of) x86 provides a side channel to find addresses of branches in the kernel. Page and heap allocation, etc., is still quite predictable. struct randomisation (RANDSTRUCT plugin from grsecurity) reorders members in (a) structures containing only function pointers (b) explicitly marked structures. This makes it very hard to attack custom kernels where the kernel image is not readable. But even for distribution kernels, it increases the maintenance burden for attackers. Deterministic protections These protections block a class of attacks completely. Read-only protection of kernel memory is either mandatory or enabled by default on x86, arm, and arm64. (Debian enables this.) Protections against execution of user memory in kernel mode are now implemented in hardware on x86 (SMEP, in Intel processors from Skylake onward) and on arm64 (PXN, from ARMv8.1). But Skylake is not available for servers and ARMv8.1 is not yet implemented at all! s390 always had this protection. It may be possible to 'emulate' this using other hardware protections. arm (v7) and arm64 now have this, but x86 doesn't. Linus doesn't like the overhead of previously proposed implementations for x86. It is possible to do this using PCID (in Intel processors from Sandy Bridge onward), which has already been done in PaX - and this should be fast enough. Virtually mapped stacks protect against stack overflow attacks. They were implemented as an option for x86 only in 4.9. (Debian enables this.) Copies to or from user memory sometimes use a user-controlled size that is not properly bounded. Hardened usercopy, implemented as an option in 4.8 for many architectures, protects against this. (Debian enables this.) Memory wiping (zero on free) protects against some information leaks and use-after-free bugs. It was already implemented as debug feature with non-zero poison value, but at some performance cost. Zeroing can be cheaper since it allows allocator to skip zeroing on reallocation. That was implemented as an option in 4.6. (Debian does not currently enable this but we might do if the performance cost is low enough.) Constification (with the CONSTIFY gcc plugin) reduces the amount of static data that can be written to. As with RANDSTRUCT, this is applied to function pointer tables and explicitly marked structures. Instances of some types need to be modified very occasionally. In PaX/Grsecurity this is done with pax_ open,close _kernel() which globally disable write protection temporarily. It would be preferable to override write protection in a more directed way, so that the permission to write doesn't leak into any other code that interrupts this process. The feature is not in mainline yet. Atomic wrap detction protects against reference-counting bugs which can result in a use-after-free. Overflow and underflow are trapped and result in an 'oops'. There is no measurable performance impact. It would be applied to all operations on the atomic_t type, but there needs to be an opt-out for atomics that are not ref-counters - probably by adding an atomic_wrap_t type for them. This has been implemented for x86, arm, and arm64 but is not in mainline yet. Kernel Freezer Hell For the second year running, Jiri Kosina raised the problem of 'freezing' kthreads (kernel-mode threads) in preparation for system suspend (suspend to RAM, or hibernation). What are the semantics? What invariants should be met when a kthread gets frozen? They are not defined anywhere. Most freezable threads don't actually need to be quiesced. Also many non-freezable threads are pointlessly calling try_to_freeze() (probably due to copying code without understanding it)). At a system level, what we actually need is I/O and filesystem consistency. This should be achieved by:

• Telling mounted filesystems to freeze. They can quiesce any kthreads they created.
• Device drivers quiescing any kthreads they created, from their PM suspend implementation.

The system suspend code should not need to directly freeze threads. Kernel Documentation Jon Corbet and Mauro Carvalho presented the recent work on kernel documentation. The kernel's documentation system was a house of cards involving DocBook and a lot of custom scripting. Both the DocBook templates and plain text files are gradually being converted to reStructuredText format, processed by Sphinx. However, manual page generation is currently 'broken' for documents processed by Sphinx. There are about 150 files at the top level of the documentation tree, that are being gradually moved into subdirectories. The most popular files, that are likely to be referenced in external documentation, have been replaced by placeholders. Sphinx is highly extensible and this has been used to integrate kernel-doc. It would be possible to add extensions that parse and include the MAINTAINERS file and Documentation/ABI/ files, which have their own formats, but the documentation maintainers would prefer not to add extensions that can't be pushed to Sphinx upstream. There is lots of obsolete documentation, and patches to remove those would be welcome. Linus objected to PDF files recently added under the Documentation/media directory - they are not the source format so should not be there! They should be generated from the corresponding SVG or image files at build time. Issues around Tracepoints Steve Rostedt and Shuah Khan led a discussion about tracepoints. Currently each maintainer decides which tracepoints to create. The cost of each added tracepoint is minimal, but the cost of very many tracepoints is more substantial. So there is such a thing as too many tracepoints, and we need a policy to decide when they are justified. They advised not to create tracepoints just in case, since kprobes can be used for tracing (almost) anywhere dynamically. There was some support for requiring documentation of each new tracepoint. That may dissuade introduction of obscure tracepoints, but also creates a higher expectation of stability. Tools such as bcc and IOVisor are now being created that depend on specific tracepoints or even function names (through kprobes). Should we care about breaking them? Linus said that we should strive to be polite to developers and users relying on tracepoints, but if it's too painful to maintain a tracepoint then we should go ahead and change it. Where the end users of the tool are themselves developers it's more reasonable to expect them to upgrade the tool and we should care less about changing it. In some cases tracepoints could provide dummy data for compatibility (as is done in some places in procfs).

I attended this year's Linux Kernel Summit in Santa Fe, NM, USA and made notes on some of the sessions that were relevant to Debian. LWN also reported many of the discussions. This is the first of two parts of my notes; part 2 is here. Stable process Jiri Kosina, in his role as a distribution maintainer, sees too many unsuitable patches being backported - e.g. a fix for a bug that wasn't present or a change that depends on an earlier semantic change so that when cherry-picked it still compiles but isn't quite right. He thinks the current review process is insufficient to catch them. As an example, a recent fix for a minor information leak (CVE-2016-9178) depended on an earlier change to page fault handling. When backported by itself, it introduced a much more serious security flaw (CVE-2016-9644). This could have been caught very quickly by a system call fuzzer. Possible solutions: require 'Fixes' field, not just 'Cc: stable'. Deals with 'bug wasn't present', but not semantic changes. There was some disagreement whether 'Fixes' without 'Cc: stable' should be sufficient for inclusion in stable. Ted Ts'o said he specifically does that in some cases where he thinks backporting is risky. Greg Kroah-Hartman said he takes it as a weaker hint for inclusion in stable. Is it a good idea to keep 'Cc: stable' given the risk of breaking embargo? On balance, yes, it only happened once. Sometimes it's hard to know exactly how/when the bug was introduced. Linus doesn't want people to guess and add incorrect 'Fixes' fields. There is still the option to give some explanation and hints for stable maintainers in the commit message. Ideally the upstream developer should provide a test case for the bug. Is Linus happy? Linus complained about minor fixes coming later in the release cycle. After rc2, all fixes should either be for new code introduced in the current release cycle or for important bugs. However, new, production-ready drivers without new infrastructure dependencies are welcome at almost any point in the release cycle. He was unhappy about some big changes in RDMA, but I'm not sure what those were. Bugzilla and bug tracking Laura Abbott started a discussion of bugzilla.kernel.org, talking about subsystems where maintainers ignore it and any responses come from random people giving bad advice. This is a terrible experience for users. Several maintainers are actively opposed to using it, and the email bridge no longer works (or not well?). She no longer recommends Fedora bug submitters to submit reports there. Are there any alternatives? None were proposed. Someone asked whether Bugzilla could tell reporters to use email for certain products/components instead of continuing with the bug entry process. Konstantin Ryabitsev talked about the difficulty of upgrading a customised instance of Bugzilla. Much customisation requires patches which don't apply to next version (maybe due to limitations of the extension mechanism?). He has had to drop many such patches. Email is hard to track when a bug is handed over from one maintainer to another. Email archives are very unreliable. Linus: I'll take Bugzilla over mail-archive. No-one is currently keeping track of bugs across the kernel and making sure they get addressed by an appropriate maintainer. It's (at least) a full-time job but no individual company has business case for paying for this. Konstantin suggested (I think) that CII might pay for this. There was some discussion of what information should be included in a bug report. The Cut here line in oops messages was said to be a mistake because there are often relevant messages before it. The model of computer is often important. Beyond that, there was not much interest in the automated information gathering that distributions do. Distribution maintainers should curate bugs before forwarding upstream. There was a request for custom fields per component in Bugzilla. Konstantin says this is doable (possibly after upgrade to version 5); it doesn't require patches. The future of the Kernel Summit The kernel community is growing, and the invitation list for the core day is too small to include all the right people for technical subjects. For 2017, the core half-day will have an even smaller invitation list, only ~30 subsystem maintainers that Linus pulls from. The entire technical track will be open (I think). Kernel Summit 2017 and some mini-summits will be held in Prague alongside Open Source Summit Europe (formerly LinuxCon Europe) and Embedded Linux Conference Europe. There were some complaints that LinuxCon is not that interesting to kernel developers, compared to Linux Plumbers Conference (which followed this year's Kernel Summit). However, the Linux Foundation is apparently soliciting more hardcore technical sessions. Kernel Summit and Linux Plumbers Conference are quite small, and it's apparently hard to find venues for them in cities that also have major airports. It might be more practical to co-locate them both with Open Source Summit in future. time_t and 2038 On 32-bit architectures the kernel's representation of real time (time_t etc.) will break in early 2038. Fixing this in a backward-compatible way is a complex problem. Arnd Bergmann presented the current status of this process. There has not yet been much progress in mainline, but more fixes have been prepared. The changes to struct inode and to input events are proving to be particularly problematic. There is a need to add new system calls, and he intends to add these for all (32-bit) achitectures at once. Copyright retention James Bottomley talked about how developers can retain copyright on their contributions. It's hard to renegotiate within an existing employment; much easier to do this when preparing to sign a new contract. Some employers expect you to fill in a document disclosing 'prior inventions' you have worked on. Depending on how it's worded, this may require the employer to negotiate with you again whenever they want you to work on that same software. It's much easier for contractors to retain copyright on their work - customers expect to have a custom agreement and don't expect to get copyright on contractor's software.

I was assigned 13.75 hours of work by Freexian's Debian LTS initiative and worked all of them. I reviewed the fix for CVE-2016-7796 in wheezy's systemd, which needed substantial changes and a few iterations to get right. I updated linux to the 3.2.82 stable release (and 3.2.82-rt119 for PREEMPT_RT), and added fixes for several security issues including CVE-2016-5195 "Dirty Cow". I uploaded and issued DLA-670-1. In my role as Linux 3.2 stable maintainer, I made a 3.2.83 release fixing just that issue, and started to prepare a 3.2.84 release with many more fixes. I cleaned up my work on imagemagick, but didn't go further through the backlog of issues. I put the partly updated package on people.debian.org for another LTS maintatainer to pick up.

Debian Long Term Support (LTS) This is my 7th month working on Debian LTS, started by Raphael Hertzog at Freexian, after a long pause during the summer. I have worked on the following packages and CVEs:

• tre: CVE-2016-8859
• graphicsmagick: CVE-2016-7448, CVE-2016-7996, CVE-2016-7997, CVE-2016-8682, CVE-2016-8683, CVE-2016-8684
• tar: CVE-2016-6321

I have also helped review work on the following packages:

• imagemagick: reviewed BenH's work to figure out what was done. unfortunately, I forgot to officially take on the package and Roberto started working on it in the meantime. I nevertheless took time to review Roberto's work and outline possible issues with the original patchset suggested
• tiff: reviewed Raphael's work on the hairy TIFFTAG_* issues, all the gory details in this email

The work on ImageMagick and GraphicsMagick was particularly intriguing. Looking at the source of those programs makes me wonder why were are still using them at all: it's a tangled mess of C code that is bound to bring up more and more vulnerabilities, time after time. It seems there's always an "Magick" vulnerability waiting to be fixed out there... I somehow hoped that the fork would bring more stability and reliability, but it seems they are suffering from similar issues because, fundamentally, they haven't rewritten ImageMagick... It looks this is something that affects all image programs. The review I have done on the tiff suite give me the same shivering sensation as reviewing the "Magick" code. It feels like all image libraries are poorly implemented and then bound to be exploited somehow... Nevertheless, if I had to use a library of the sort in my software, I would stay away from the "Magick" forks and try something like imlib2 first... Finally, I also did some minor work on the user and developer LTS documentation and some triage work on samba, xen and libass. I also looked at the dreaded CVE-2016-7117 vulnerability in the Linux kernel to verify its impact on wheezy users. I also looked at implementing a --lts flag for dch (see bug #762715). It was difficult to get back to work after such a long pause, but I am happy I was able to contribute a significant number of hours. It's a bit difficult to find work sometimes in LTS-land, even if there's actually always a lot of work to be done. For example, I used to be one of the people doing frontdesk work, but those duties are now assigned until the end of the year, so it's unlikely I will be doing any of that for the forseable future. Similarly, a lot of packages were assigned when I started looking at the available packages. There was an interesting discussion on the internal mailing list regarding unlocking package ownership, because some people had packages locked for weeks, sometimes months, without significant activity. Hopefully that situation will improve after that discussion. Another interesting discussion I participated in is the question of whether the LTS team should be waiting for unstable to be fixed before publishing fixes in oldstable. It seems the consensus right now is that it shouldn't be mandatory to fix issues in unstable before we fix security isssues in oldstable and stable. After all, security support for testing and unstable is limited. But I was happy to learn that working on brand new patches is part of our mandate as part of the LTS work. I did work on such a patch for tar which ended up being adopted by the original reporter, although upstream ended up implementing our recommendation in a better way. It's coincidentally the first time since I start working on LTS that I didn't get the number of requested hours, which means that there are more people working on LTS. That is a good thing, but I am worried it may also mean people are more spread out and less capable of focusing for longer periods of time on more difficult problems. It also means that the team is growing faster than the funding, which is unfortunate: now is a good time as any to remind you to see if you can make your company fund the LTS project if you are still running Debian wheezy.

Other free software work It seems like forever that I did such a report, and while I was on vacation, a lot has happened since the last report.

Monkeysign I have done extensive work on Monkeysign, trying to bring it kicking and screaming in the new world of GnuPG 2.1. This was the objective of the 2.1 release, which collected about two years of work and patches, including arbitrary MUA support (e.g. Thunderbird), config files support, and a release on PyPI. I have had to release about 4 more releases to try and fix the build chain, ship the test suite with the program and have a primitive preferences panel. The 2.2 release also finally features Tor suport! I am also happy to have moved more documentation to Read the docs, part of which I mentionned in in a previous article. The git repositories and issues were also moved to a Gitlab instance which will hopefully improve the collaboration workflow, although we still have issues in streamlining the merge request workflow. All in all, I am happy to be working on Monkeysign, but it has been a frustrating experience. In the last years, I have been maintaining the project largely on my own: although there are about 20 contributors in Monkeysign, I have committed over 90% of the commits in the code. New contributors recently showed up, and I hope this will release some pressure on me being the sole maintainer, but I am not sure how viable the project is.

Funding free software work More and more, I wonder how to sustain my contributions to free software. As a previous article has shown, I work a lot on the computer, even when I am not on a full-time job. Monkeysign has been a significant time drain in the last months, and I have done this work on a completely volunteer basis. I wouldn't mind so much except that there is a lot of work I do on a volunteer basis. This means that I sometimes must prioritize paid consulting work, at the expense of those volunteer projects. While most of my paid work usually revolves around free sofware, the benefits of paid work are not always immediately obvious, as the primary objective is to deliver to the customer, and the community as a whole is somewhat of a side-effect. I have watched with interest joeyh's adventures into crowdfunding which seems to be working pretty well for him. Unfortunately, I cannot claim the incredible (and well-deserved) reputation Joey has, and even if I could, I can't live with 500$ a month. I would love to hear if people would be interested in funding my work in such a way. I am hesitant in launching a crowdfunding campaign because it is difficult to identify what exactly I am working on from one month to the next. Looking back at earlier reports shows that I am all over the place: one month I'll work on a Perl Wiki (Ikiwiki), the next one I'll be hacking at a multimedia home cinema (Kodi). I can hardly think of how to fund those things short of "just give me money to work on anything I feel like", which I can hardly ask for of anyone. Even worse, it feels like the audience here is either friends or colleagues. It would make little sense for me to seek funding from those people: colleagues have the same funding problems I do, and I don't want to empoverish my friends... So far I have taken the approach of trying to get funding for work I am doing, bit by bit. For example, I have recently been told that LWN actually pays for contributed articles and have started running articles by them before publishing them here. This is looking good: they will publish an article I wrote about the Omnia router I have recently received. I give them exclusive rights on the article for two weeks, but I otherwise retain full ownership over the article and will publish them after the exclusive period here. Hopefully, I will be able to find more such projects that pays for the work I do on a day to day basis.

Open Street Map editing I have ramped up my OpenStreetMap contributions, having (temporarily) moved to a different location. There are lots of things to map here: trails, gaz stations and lots of other things are missing from the map. Sometimes the effort looks a bit ridiculous, reminding me of my early days of editing OSM. I have registered to OSM Live, a project to fund OSM editors that, I must admit, doesn't help much with funding my work: with the hundreds of edits I did in October, I received the equivalent of 1.80$CAD in Bitcoins. This may be the lowest hourly salary I have ever received, probably going at a rate of 10 per hour! Still, it's interesting to be able to point people to the project if someone wants to contribute to OSM mappers. But mappers should have no illusions about getting a decent salary from this effort, I am sorry to say.

Bounties I feel this is similar to the "bounty" model used by the Borg project: I claimed around $80USD in that project for what probably amounts to tens of hours of work, yet another salary that would qualify as "poor". Another example is a feature I would like to implement in Borg: support for protocols other than SSH. There is currently no bounty on this, but a similar feature, S3 support has one of the largest bounties Borg has ever seen: $225USD. And the claimant for the bounty hasn't actually implemented the feature, instead backing up to S3, the patch (to a third-party tool) actually enables support for Amazon Cloud Drive, a completely different API. Even at $225, I wouldn't be able to complete any of those features and get a decent salary. As well explained by the Snowdrift reviews, bounties just don't work at all... The ludicrous 10% fee charged by Bountysource made sure I would never do business with them ever again anyways.

Other work

• fixed a bug in python's setuptools_scm that was a blocker for Monkeysign's use of the package to avoid duplicating version numbers everywhere...
• tried to figure out how activitypub was going to work with existing social networking software (TL;DR: it won't)
• improved the sicherboot README so that others that come after me will better understand how that secure boot system works
• more charybdis IRCd work: SIGABRT on jessie and another segfault, still more issues pending here, even
• arbitrary source URL support for the Sphinx Alabaster theme
• a bunch of issues on unattended-upgrades: raspbian configuration fails and point releases upgrades

There are probably more things I did recently, but I am having difficulty keeping track of the last 5 months of on and off work, so you will forgive that I am not as exhaustive as I usually am.

I was assigned 12.3 hours of work by Freexian's Debian LTS initiative and carried over 1.45 from last month. I was unwell for much of this month and only worked 6 hours on LTS. I returned 7 hours to the pool and carry over 0.75 hours. I wrote and sent the DLA for linux 3.2.81-2, and I discussed various handling of various issues on the debian-lts mailing list. Most of my time was spent working on the long backlog of security issues in imagemagick. I hope to complete this and upload a fixed version this month.

I was assigned 14.75 hours of work by Freexian's Debian LTS initiative and carried over 0.7 from last month. I worked a total of 14 hours, carrying over 1.45 hours. I finished preparing and finally uploaded an update for linux (3.2.81-2). This took longer than expected due to the difficulty of reproducing CVE-2016-5696 and verifying the backported fix. I also released an upstream stable update (3.2.82) which will go into the next update in wheezy LTS. I discussed a few other security updates and issues on the debian-lts mailing list.

I was assigned another 14.7 hours of work by Freexian's Debian LTS initiative and carried over 1 from last month. I worked a total of 15 hours, carrying over a fraction of an hour. I spent another week in the Front Desk role and triaged various new CVEs for wheezy. I spent the remainder of the time working on the next Linux stable updates (3.2.82 and Debian 3.2.81-2), but didn't release them - that will be done in the next few days.

I was assigned another 15 hours of work by Freexian's Debian LTS initiative and carried over 5 from last month. I worked a total of 19 hours, carrying over 1. I spent a week in the Front Desk role and triaged many new security issues for wheezy. I prepared the Linux 3.2.81 stable update, sent it out for review and finally released it. I then rebased the wheezy-security branch on top of that and added some later security fixes that were not yet suitable for a kernel.org update. I uploaded to wheezy-security and issued DLA-516-1. I started working on the next Linux stable updates (3.2.82 and the next wheezy LTS update) and on an update for imagemagick, but haven't uploaded anything for them yet.

I was assigned another 15 hours of work by Freexian's Debian LTS initiative, but only worked a total of 10 hours. I intend to make up for this in June. I began preparing the next stable update for Linux 3.2 on kernel.org, but haven't yet sent it out for review. I rebased the wheezy-security branch onto Linux 3.2.80, and added fixes for one more security issue and one data corruption issue affecting aufs. I started a week in the front desk, triaging new issues for wheezy.

On 1st May 2006 my Debian account was created and I gained the status of Debian Developer. At that time I had already been to several BSPs and one DebConf, and maintained a few applications and Perl library packages. We were working toward the etch release and would soon hold DebConf 6 in Mexico. Ten years later, I still maintain one of those packages (sgt-puzzles) but the rest were either handed over to the Perl team or entirely removed. I wrote, maintained, and then gave away dvswitch all within this period. I have packaged some other applications that I needed to use - kup, ministat, odhcp6c - and I continue to maintain them. I have also made many NMUs, including security uploads, for all kinds of packages including bind9, e2fsprogs, (e)glibc, lvm2, sudo, sysvinit and udev. However, for about the past 7 years most of my work in Debian has been done within the kernel team, working on the Linux kernel and closely related packages - such as crda, ethtool, firmware-nonfree and initramfs-tools. I have also become an upstream developer for several of these projects. I'm proud to have played a part in the etch, lenny, squeeze, wheezy and jessie releases, and I have enjoyed attending 7 more DebConfs and many mini-DebConfs. I'm now looking forward to another great release (stretch) and to attending DebConf 16 in Cape Town this summer winter. I hope to still be active in Debian in 2026, looking back on another 10 years in this amazing project.

This month was still quiet for me in terms of uploads, as "wheezy" was only handed over to the LTS team near the end of the month. I carried over 5.5 hours from March and was assigned another 15 hours of work by Freexian's Debian LTS initiative, but only worked a total of 12.25 hours. I have returned the spare hours to the pool. As last month, I prepared a stable update for Linux 3.2 on kernel.org, which will be released soon as 3.2.80. I also triaged the open security issues and backported a few individual patches to our wheezy-security branch. However I expect to rebase the wheezy-security branch onto Linux 3.2.80 before making the next upload. I also participated in discussion of supporting armel/armhf in wheezy LTS. I don't expect many LTS users to be using the Debian kernel packages, as we only supported a small range of ARM hardware before the introduction of the multiplatform flavours in jessie. However, those architectures rarely require any extra effort to support in linux stable updates so I had no objection to including them.

I've lately been working on support for Secure Boot in Debian, mostly in the packages maintained by the kernel team. My instructions for setting up UEFI Secure Boot are based on OVMF running on KVM/QEMU. All 'Designed for Windows' PCs should allow reconfiguration of SB, but it may not be easy to do so. They also assume that the firmware includes an EFI shell. Updated: Robert Edmonds pointed out that the 'Designed for Windows' requirements changed with Windows 10:

@benhutchingsuk "Hardware can be Designed for Windows 10 and can offer no way to opt out of the Secure Boot" https://t.co/lQVdPYtMwx Robert Edmonds (@rsedmonds) April 20, 2016

The ability to reconfigure SB is indeed now optional for devices which are designed to always boot with a specific Secure Boot configuration. I also noticed that the requirements say that OEMs should not sign an EFI shell binary. Therefore I've revised the instructions to use efibootmgr instead. Background UEFI Secure Boot, when configured and enabled (which it is on most new PCs) requires that whatever it loads is signed with a trusted key. The one common trusted key for PCs is held by Microsoft, and while they will sign other people's code for a nominal fee, they require that it also validates the code it loads, i.e. the kernel or next stage boot loader. The kernel in turn is responsible for validating any code that could compromise its integrity (kernel modules, kexec images). Currently there are no such signed boot loaders in Debian, though the shim and grub-signed packages included in many other distributions should be usable. However it's possible to load an appropriately configured Linux kernel directly from the UEFI firmware (typically through the shell) which is what I'm doing at the moment. Packaging signed kernels Signing keys obviously need to be protected against disclosure; the private keys can't be included in a source package. We also won't install them on buildds separately, and generating signatures at build time would of course be unreproducible. So I've created a new source package, linux-signed, which contains detached signatures prepared offline. Currently the binary packages built from linux-signed also contain only detached signatures, which are applied as necessary at installation time. The signed kernel image (only on x86 for now) is named /boot/vmlinuz-kversion.efi.signed. However, since packages must not modify files owned by another package and I didn't want to dpkg-divert thousands of modules, the module signatures remain detached. Detached module signatures are a new invention of mine, and require changes in kmod and various other packages to support them. (An alternate might be to put signed modules under a different directory and drop a configuration file in /lib/depmod.d to make them higher priority. But then we end up with two copies of every module installed, which can be a substantial waste of space.) Preparation The packages you need to repeat the experiment:

• linux-image-4.5.0-1-flavour version 4.5.1-1 from unstable (only 686, 686-pae or amd64 flavours have signed kernels; most flavours have signed modules)
• linux-image-4.5.0-1-flavour-signed version 1~exp3 from experimental
• initramfs-tools version 0.125 from unstable
• kmod and libkmod2 unofficial version 22-1.2 from people.debian.org

For Secure Boot, you'll then need to copy the signed kernel and the initrd onto the EFI system partition, normally mounted at /boot/efi. SB requires a Platform Key (PK) which will already be installed on a real PC. You can replace it but you don't need to. If you're using OVMF, there are no persistent keys so you do need to generate your own:

openssl req -new -x509 -newkey rsa:2048 -keyout pk.key -out pk.crt \
    -outform der -nodes

You'll also need to install the certificate for my kernel image signing key, which is under debian/certs in the linux-signed package. OVMF requires this in DER format:

openssl x509 -in linux-signed-1~exp3/debian/certs/linux-image-benh@debian.org.cert.pem \
    -out linux.crt -outform der 

You'll need to copy the certificate(s) to a FAT-formatted partition such as the EFI system partition, so that the firmware can read it. Use efibootmgr to add a boot entry for the kernel, for example:

efibootmgr -c -d /dev/sda -L linux-signed -l '\vmlinuz.efi' -u 'initrd=initrd.img root=/dev/sda2 ro quiet'

You should use the same kernel parameters as usual, except that you also need to specify the initrd filename using the initrd= parameter. The EFI stub code at the beginning of the kernel will load the initrd using EFI boot services. Enabling Secure Boot

1. Reboot the system and enter UEFI setup
2. Find the menu entry for Secure Boot customisation (in OVMF, it's under 'Device Manager' for some reason)
3. In OVMF, enrol the PK from pk.crt
4. Add linux.crt to the DB (whitelist database)
5. Ensure that Secure Boot is enabled and in 'User Mode'

Booting the kernel in Secure Boot If all went well, Linux will boot as normal. You can confirm that Secure Boot was enabled by reading /sys/kernel/security/securelevel, which will contain 1 if it was. Module signature validation Module signatures are now always checked and unsigned modules will be given the 'E' taint flag. If Secure Boot is used or you add the kernel parameter module.sig_enforce=1, unsigned modules will be rejected. You can also turn on signature enforcement and turn off various other methods of modifying kernel code (such as kexec) by writing 1 to /sys/kernel/security/securelevel.

Last month was relatively quiet for me in terms of uploads, as the "squeeze" LTS period was over and "wheezy" is still in the hands of the regular Debian security team. I carried over 7.25 hours from Feburary and was assigned another 11 hours of work by Freexian's Debian LTS initiative, and worked a total of 12.75 hours. As Debian 7 "wheezy" uses Linux 3.2.y, I took on maintenance of that stable branch at kernel.org from May 2012 until wheezy's EOL. (This currently makes it both the oldest of the kernel.org supported releases and the one with the latest projected EOL!) I will now be maintaining it as part of my Debian LTS work, and then taking on Linux 3.16.y in my own time starting next month. Each update takes me around 10 hours to prepare, so Linux 3.2.79 accounted for most of my work this month. Aside from that, I backported an additional security fix for the kernel (that was not yet suitable for a kernel.org update) to the wheezy-security branch, rebased the wheezy branch on 3.2.79, and pulled upstream updates to the PREEMPT_RT patchset.

There was a connection I meant to draw, and then forgot to do before publishing my last entry. In severe cases of depression, ECT may still be used as a last resort, and is often effective. I had the idea that the lesser shock to the brain of a high fever might somehow have an effect on less serious depression. It doesn't seem terribly likely, though, and we never did find a thermometer to check just how high my temperature was.

Some of you (but though probably not many) will know that I've suffered from depression at times. It has made it very difficult for me to do my job, to keep my home in order, even to have real conversations. Many important tasks seemed to require more energy than I had, and every setback left me feeling hopeless. I have sought treatment on several occasions, with very limited results. Certainly I would get better eventually, but it was hard to tell whether this had anything to do with the medication or therapy I received. And even while I felt better, I still didn't feel particularly happy or hopeful except when going to my favourite social events like DebConf. As I was recovering from the 'flu a weeks ago, I realised that I was feeling enthusiastic and energetic for no particular reason. Obviously I was recovering from physical illness, but that was brief. I had also just started a new project at work, but it isn't that exciting (at this stage) and I'm already aware of plenty of problems with it. So nothing external seemed to have changed to make me feel better, and yet my mood was so high that I worried that my illness could have changed to bipolar disorder and that I was entering a manic phase.

Feeling better mentally than I have in at least 6 months. Unfortunately my head's been buzzing with thoughts that kept me awake all night. Ben Hutchings (@benhutchingsuk) 29 February 2016

Thankfully, I'm not behaving manically. I have been doing a lot more shopping than usual, but almost the first purchase was a whiteboard to maintain the to-do list that I had been keeping rather unreliably in my head, and mostly I've been buying things off that list - that I've intended to get for months or years. It's just been so long since I could feel generally positive and optimistic about my life - outside of any special event - that I didn't immediately recognise this state of mind as normality.

@benhutchingsuk Did I say 6 months? I think it's more like a decade. There's a pretty deep pile of stuff I'm finally dealing with... Ben Hutchings (@benhutchingsuk) 7 March 2016

It's now been two three weeks since my recovery, and I still feel so much better:

• I'm bothered far less by discomforts like feeling a little cold or hungry. I used to become almost paralysed by this, while feeling too short of energy to fix myself some food.
• Pleasure is more intense. Food tastes and smells wonderful. Music feels more immersive. Sex made me cry.
• I can easily have normal conversations with people I know and people I don't. I'm having important conversations I had been putting off.
• I'm also able to write personal things like this, that I've shied away from for years.
• When I see minor problems with the flat, I either fix them straight away or put them on the whiteboard to be fixed soon.
• I'm far more persistent. If I run into an obstacle I'll either try a different approach or add an item to the whiteboard for whatever tools or supplies I'm missing.

As I feel better in myself I also find myself less self-centred and more able to focus on other people's needs, particularly my wife Nattie. Frankly I've been an asshole pretty often while I was depressed, so I apologise to those who've been the brunt of that. I hope you'll find me more pleasant to deal with from now on. There's lots more I could write, but I'll end this entry now and maybe say more at a later date.

Last Monday, I began a new project at Codethink - working on kernel support for the next generation of an interactive system fitted in some high-performance cars. I travelled up to Manchester the night before, and on Monday I met Codethink's team (most of whom I was familiar with). My first chore was to set up VPN access to the development resources (source control, wiki, etc.). I sandboxed the proprietary VPN client in a VM with a systemd unit to run it at boot, so I can control it by starting and stopping that VM. I then set to work on unpacking and exploring the SoC vendor's evaluation module (EVM), starting by looking at serial output - of which there was none. Nothing on the LCD panel or network port either. A frustrating day. On Tuesday, the architect from our immediate customer, already a friend of mine, joined us in Manchester. As for the EVM, without any obvious change in cabling it was now reliably spitting out the expected u-boot and kernel boot messages, unfortunately ending with errors from the touchscreen driver intermingled with messages from various graphics drivers. I looked at the u-boot environment to see how the kernel parameters were controlled and started tweaking them with the aim of working around the errors. None of this worked. I looked for more documentation on the EVM, but found none beyond the quick start guide. Had I been given the wrong kernel or device tree? They matched the available downloads though the device tree looked very different from the upstream version. I started trying to edit the vendor's device tree to remove the troublesome devices before realising that the decompiled tree was full of absolute cross-references that would be invalid after recompiling. So, a second day of frustration. In the evening I started to feel a cold coming on. I slept poorly, and just dragged myself out of bed in time for 11:00 checkout. In the office, I remembered that u-boot had commands for manipulating device trees in memory. I tried stepping through the boot script and then removing device tree nodes for the touchscreen and graphics hardware before booting the kernel. Success! I got a login prompt where of course username:root, password:[empty] worked. (It doesn't run sshd, but does run telnetd.) Then it was time for a team lunch at the excellent Samsi, though I hesitated to go as I was feeling quite poorly. Shortly after lunch I found myself falling asleep at my desk in the middle of reading documentation. I had to take a nap on the sofa. I got a little more work done that day, but I got progressively feebler. The train journey home was thankfully uneventful. I arrived home at midnight and soon went to sleep. I spent most of Thursday in a high fever, dreaming of abstract entities and their relationships that I struggled to name, but in retrospect might correspond to various kinds of software component. It was incredibly tedious. I had no appetite and little ability to process the real world. Nattie tended to me as she could. I called my mum to cancel her visit planned for the next day. On Friday my fever started to recede and I drank some soup. I was able to look after myself to some extent, though I sorely missed Nattie when she went out. I spent most of the day watching comedy and music docs on the BBC iPlayer, something far too passive for me to do normally. On Saturday morning I felt well enough to tackle the meze platter that Nattie brought back from her previous evening's outing. It tasted pretty damn good. I felt better hour by hour, and in the evening we both went out to a group dinner in a pub. Hot food smelled and tasted even more amazing! I was able to start catching up on email and some real work, preparing kernel stable updates. I even migrated DNS service for decadent.org.uk late that night, driven by anger at the incompetence of my previous provider that had prevented my mails reaching bugs.debian.org. Despite the awfulness of Thursday and the symptoms I still have (tickly throat and runny nose), this bout of the 'flu has been a positive experience for me, but I'll explain why that is in a subsequent entry.